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4J0 Authentisierung XP-Q02201839 {Cf^ ~ Jq3 ]gj 

Nachdem also das Terminal den fur diese Kane notwendigen Authentisieruno-s- 
schlussel errechnet hat, folgt der ubliche Ablauf im Rahmen des Challenge-Response- 
Verfahrens. Die Chipkarte erhalt vom Terminal eine Zufallszahl, verschlusselt diese 
niit ihrem kartenindividuellen Schlussel und sendet sie an das Terminal zuriick. Dieses 
fiihrt analog der Chipkarte die Urnkehrfunktion der Berechnung aus und vergleicht die 
beiden Ergebnisse. Stirrunen sie iiberein, so besitzen sowohl Chipkarte als auch Termi- 
nal ein gemeinsames Geheimnis, namlich den geheimen kartenindividuellen Schlussel, 
und die Chipkarte ist vom Terminal authentisiert. 

Der Vorgang der Authentisierung ist durch den Aufruf von DES-Algorithmen und 
i e D a t ftn i i b e rtr a g urig von und^uP-Karte-erwag-zeitintensiv, Die s k a nn b erm anchen 
Anwendungen zu Problemen fuhren. 

Unter den folgenden Annahmen kann man den Zeitbedarf fur eine einseitise Au- 
thentisierung uberschlagsmaBig eirechnen. Angenommen sei eine Chipkarte mif einem 
Takt von 3,5 MHz, dem Ubertragungsprotokoll T=l, einem Teiler von 372 und einem 
DES-Algorithmus, der 17 ms fur einen Block benotigt. Alle internen Routinen der 
Chipkarte seien hier ohne genauere Angabe mit 9 ms angenommen, was die Berech- 
nung vereinfacht, das Endergebnis aber nur unwesentlich verfalscht. 

Tabelle 4.17 Berechnung des Zeitbedarfs in der Chipkarte fur eine einseitige Authentisienin* 
unter Beriicksichtigung der ObertragungszeiL 

Kommando Zeitbedarf fur Zeitbedarf fur 

- Ubertragung Berechnung 

INTERNAL AUTHENTICATE 38.75 ms I 26rnl = 64,75 ms 

Man sieht deutlich anhand der Berechnung, daB eine einzige Authentisierung ca. 
65 ms benotigt. Dies kann im Normalfall in einer Anwendung ohne zeidiche Probleme 
ausgefuhrt werden. 

4.10.2 Gegenseitige symmetrische Authentisierung 

Das Prinzip der gegenseitigen Authentisierung (mutual authentication) beruht auf ei- 
ner zweifachen einseitigen Authentisierung. Man konnte auch zwei einseitige Authen- 
tisierungen abwechselnd fur beide Kommunikationspartner ausfuhren. Dies°ware dann 
im Prinzip eine gegenseitige Authentisierung. Da jedoch der Kommunikationsaufwand 
aus zeitlichen Grunden so gering wie moglich gehalten werden muB, gibt es ein Ver- 
fahren, in dem die beiden einseitigen Authentisierungen miteinander verflochten sind. 
Dabei erzielt man auch noch eine hohere Sicherheit als mit zwei nacheinander ausge- 
fuhrten Authentisierungen, da es fur einen Angreifer viel schwieriger ist, in den Korn- 
munikationsablauf einzugreifen. 

Damit das Terminal mit dem Hauptschliissel aus der Kartennummer den karten- 
individuellen Authentisierungsschlussel berechnen kann, benotigt es als erstes die 
Kartennummer. Nachdem das Terminal die Kartennummer erhahen hat, berechnet es 
den individuellen Authentisierungsschlussel fur diese Chipkarte. Dann fordert es von 
der Chipkarte eine Zufallszahl an und generiert selbst ebenfalls eine Zufallszahi. Nun 
setzt das Terminal beide Zufallszahlen vertauscht hintereinander. verschlusselt sie mit 
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dem geheimen Authentisierungsschlussel und sendet den erhaltenen Schlusseltext zur 
mSL VeitaUSChen hat den Zwe * Challenge und Response unterschiedlich zu 

Diese kann den erhaltenen Block entschlusseln und priifen, ob die vorher an das 
Terminal gesendete Zufallszahl mit der zuriickerhaltenen ubereinstimmt s dies de 
FaU so we,S d ; e Chipkarte, daB das Tenninal den geheimen Schlussel be ste Daml 

' kite dfe Td S ?Tn ber M ' ^^thendsienrD^ufhin- vertauscht die Clip- " 
karte die beiden Zufallszahlen, verschlusselt sie mit dem geheimen Schlussel und 
schickt das Ergebniszum Terminal. en ^cmusseJ und 

Das Terminal entschlusselt den erhaltenen Block und vergleicht die zuvor an die 
Chipkarte gesendete Zufallszahl mit der erhaltenen. Sdmmt diese mit der vormals *e 
nnrntt tn ' S ° 1St aUCh die ^ S e S enUber dem Tenninal authentisie°rt 
a^c^l , Se§enSei i 1 ?^ UthendSierang ab ^hlossen, und sowohl Chipkarte als 
auch Terminal wissen, daB der jeweilig andere vertrauenswiirdi* i st 

Um den Zeitbedarf der Kommunikation zu minimieren, kann die Chipkarte-zusatz.- 
-Tich zur Kartennummer auch noch die Zufallszahl zurUcksenden. Ses'SST^TS 
teresse, wenn die gegenseitige Authendsierung zwischen Chipkarte und einem Hinter 
grundsystem stattfindet. Die Chipkarte wird dabei direkt vom Himcr^toS, 
^ansparent zum Tenninal angesprochen. Die DatenubertragungsgeschXd^t Z 
SS" d ^ K — onsablauf muB dadurch so stark wiem^ 
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Bild 4.47 



Die gegenseitige Authentisierung mit kartenindividuellem Schlussel und einem 
symrnetnschen Kryptoalgorithmus. Der Ablauf entspricht einer gegensei ti © en Aai- 

AUTHENTICATE nach ISO/IEC 78 1 6-8 realisiert werden kann. 

Um den erheblichen Zeitaufwand, auch im Gegensatz zur einseiticen Authenti 
^erung aufzuze,gen ist im folgenden nochmals eine rechnerische Be^un^t 
fuhrt. D>e zugrundehegenden Annahmen sind dabei analog der einseitigen Autheml 
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sierung. Man sieht, daB die gegenseitige Authentisierung beinahe dreimal so lanoe 
dauert als eine einseitige. ° 

Tabelle 4.18 Berechnung des Zeitbedarfs in der Chipkane fur eine geoenseitige Authentisierung 
unter Berucksichtigung der Obertragungszeit. Es wurde anaenommen, daB keine ab^ 
geleiteten Schlussel Verwendung finden (GET CHIP NUMBER ist deshalb nicht 
notwendig). 

Kommando Zeitbedarf fur Zeitbedarf filr 

Obertragung Berechnung 



ASK RANDOM 28.75 ms 26 ms 

MUTUAL AUTHENTICATE 68.75 ms 95 ms 



-9-7r50-ms r 121 ms =218,50 ms 



4.10.3 Statische asymmetrische Authentisierung 

Nur sehr wenige Chipkarten-Mikrocontrbller besitzen eine Recheneinheit, mit der 
RSA-Berechnungen durchgefuhrt werden konnen. Dies liegt vor allem daran, daB diese 
zusatzlichen Platz auf dem Chip benotigt, was den Preis erhoht. 

Da nun aber ein zusatzliches asymmetrisches Authentisierungsverfahren vermehrten 
Schutz bedeutet, da ein Angreifer nicht nur einen kryptografischen Algorithmus bre- 
chen muB, sondem zwei, mochte man oft noch diese Art von Authentisierung verwen- 
den. Urn das Problem der nicht vorhandenen Recheneinheit auf der Chipkarte zu um- 
gehen, fand man als Ausweg eine statische Authentisierung der Chipkarte durch das 
Terminal. Diese erfordert lediglich eine Verifizierung im Terminal. Eine zusatzliche 
Recheneinheit auf dem Terminal erhdht aber die Kosten im Verhaltnis zum Ge- 
samtpreis dieser Gerate nur unwesentlich, deshalb ist dieser Weg wesentlich kosten- 
gunstiger als die Verwendung spezieller Chipkarten-Mikrocontroller. Zudem ist das 
Verfahren wesentlich schneller, da nur eine asymmetrische Verschliisselung notwendig 
ist, im Gegensatz zu zwei bei einer dynamischen asymmetrischen Authentisierung 

Man erkauft sich diesen KompromiB jedoch durch eine verminderte Sicherheit des 
Authentisierungsverfahrens. Ein Schutz gegen Wiedereinspielung ist durch das stati- 
sche Verfahren natiirlich nicht gegeben. Deshalb benutzt man es auch nur als zu- 
satzliche Uberprufung der Authentizitat der Karte, die vorher schon mit einem dynami- 
schen symmetrischen Verfahren iiberpruft worden ist. 

Das Verfahren funktioniert in seinem grundlegenden Ablauf folgendermaBen: Bei 
der Personalisierung werden in jede Chipkarte kartenindividuelle Daten eingetragen 
Dies smd beispielsweise eine Kartennummer, der Name des Kartenbesitzers und seine 
Adresse. Uber diese Daten. die wahrend der Lebensdauer der Karte nicht veranderbar 
sind, wird wahrend der Personalisierung eine digitale Signatur mit einem geheimen 
Schlussel gerechnet. Der Schlussel wird im System global verwendet. Benutzt man nun 
diese Karte an einem Terminal, so liest dieses aus einer Datei auf der Kane die Signa- 
tur und die signierten Daten aus. Das Terminal besitzt den fur alle Chipkarten gultigen 
offentlichen Schlussel und kann die gelesene Signatur verschlusseln und das Ergebnis 
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5 Chipkarten- Betriebssysteme 



5.10 Chipkarten-Betriebssysteme mit nachladbarem Programm- 
code 

Der Abschnitt ..nachladbarer Programmcode" umfaBte 1995 in der ersten deutschen 
Auflage dieses Buches genau 642 Worter, geschrieben in 65 Zeilen. Der Textumfan* 
. .. in dieser Auflage mitderweile auf dasJ8fache.gestiegen. Al]ein dieser Punfct zei*r 
wie wichtig dieses Thema mittlerweile geworden ist. Man kann wohl ohne zu ubertrei- 
ben behaupten, daB sich hier innerhalb eines Jahres (1997/1998) ein Paradi^menwech- 
sel vollzogen hat. Nachladbarer Programmcode in Chipkarten wird mittlerweile als 
Regelfall und nicht mehr als Ausnahme angesehen, obwohl er noch von den weni°sten 
Chipkarten-Betriebssystemen unterstutzt wird. 

Die Griinde, warum das Nachladen von ausfuhrbarem Programmcode so stark an 
Bedeutung gewonnen hat, sind audi riickblickend nicht ganz eindeutig nachvollzieh- 
bar. Erne Triebfeder mag der im Jahr 1994 bekanntgewordene Rechenfehler (FDIV- 
berem; in aen damals weit verbreiteten Pentium-Prozessoren gewesen sein Eine Aus- 
besserung per Software-Download war nicht moglich, da es ein echter Fehler in der 
Hardware war. Allerdings gab es fur viele Anwendungsprogramme Patches, urn den 
Fehler zu umgehen. 

Es ist wahrscheinlich, daG dieser Fehler dazu fuhrte, daB mit geringer zeitlicher Ver- 
zogerung einige groBe Systembetreiber plotzlich die MSglichkeit vorsahen, ausfuhrba- 
ren Programmcode in Chipkarten nachzuladen. Eine der groBten Anwendun^en mit 
ausfuhrbarem Programmcode ist die ec-Karte mit Chip in Deutschland. Allerdings 
wird diese technische Moglichkeit zur Zeit nicht genutzt und stellt De-facto nur einen 
Rettungsanker fur eventuell auftretende schwerwiegende Programmfehler dar Auch 
bei GSM existieren Betriebssysteme, die es ermoglichen, daB Programmcode fur spe- 
zieUe Anwendungen iiber die Luftschnittstelle nachgeladen werden kann. 

Im Gegensatz zu alien anderen Betriebssystemen fur Computer ist es aber nicht o e - 
nerell ubhch, Programme in Chipkarten nach Ausgabe einzubringen und dort bei Be- 
darf auszufuhren. Dies ist aber eigentlich neben der Datenspeicherung eine der Haupt- 
fimktionen aller Betriebssysteme. Es gibt naturlich Grunde, warum bisher gerade diese 
Funktionalitat m der Chipkartenwelt weitgehend gefehlt hat. 

Technisch und funktionell gesehen stellt ausfuhrbarer Programmcode, beispielswei- 
se in Dateien (d.h. EFs) gespeichert, keinerlei Problem dar. Neuere Betriebssysteme 
bieten deshalb auch die Moglichkeit, Dateien mit ausfuhrbarem Code zu verwalten und 
auch zu einem Zeitpunkt nach der Personalisierung in die Chipkarte zu laden Damit ist 
es moglich. daB beispielsweise ein Anwendungsanbieter Programmcode in der Chip- 
karte ausfuhren kann, den der Betriebssystem-Hersteller nicht kennt. So kann ein An- 
wendungsanbieter einen nur ihm selbst bekannten Verschlusselungsalgorithmus in die 
Chipkarte einbnngen und dort ausfuhren. Hierdurch ist es moglich, das Wissen um die 
Sicherheitsfunktionen des Systems auf verschiedene Parteien zu verteilen, was eine 
Grundforderung in Sicherheitssystemen ist. 

Ein weiterer gewichtiger Grund fiir den Mechanismus des nachladbaren Pro- 
grammcodes ist die sich damit eroffnende Moglichkeit der Beseitigung von Programm- 
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fehlem (bug-fixing) in vollstandig personalisierten Karten. Erkannte Fehler im Be- 
triebssystem konnen damit bei bereits ausgegebenen Karten behoben oder zumindest 
entscharft werden. 

Es gibt grundsatzlich zwei Wege, Programmcode in einer Chipkarte auszufiihren. 
Der erste und technisch einfachste Weg ist, compilierten Code in der Maschinenspra-. 
cbe des Zielprozessors (native code) in Dateien der Chipkarte zu laden. Dieser Pro- 
grammcode muB natiirlich relokierbar sein, da die Speicheradressen nach auBen nicht 
bekannt sind. Neben der technischen Unkompliziertheit dieser Losung kann der Pro- 
grammcode noch mit voller Ausfiihrungsgeschwindigkeit des Prozessors abgearbeitet 
werden, was diese Losung gerade fur nachladbare Algorithmen sehr interessant macht. 
Weiterhin ist auch kein zusatzlicher Programmcode fur einen Interpreter in der Chip- 
karte notwendig. Das groBe Problem dieser Losung ist, daB der nachgeladene Pro- 
grammcode bei Mikrocontrollern ohne MMU (memory management unit) auch auf 
Speicherbereiche von Fremrlanwend u ngen z u greifen kann. 

Der zweite Weg, ausfiihrbaren Programmcode in Chipkarten auszufiihren, besteht 
darin, ihn zu interpretieren. Der Interpreter priift dann wahrend der Programmausfuh- 
rung, welche Speicherbereiche angesprochen werden. Die Interpretation muB aber 
schnell ablaufen, da ein langsam ausgefuhrter Programmcode keine Vorteile mehr 
bringt. Ebenso soil die Implementation eines Interpreters selber sowenig Speicher wie 
moglich in Anspruch nehmen, da dieser bekanntermaBen stark limitiert ist. Die derzei- 
tig bekanntesten Losungsvarianten dazu sind die Java Card Spezifikation [Javasoft, 
JCF] und der C-Interpreter MEL (Multos executable language) von Multos [Maosco]. 
Mittlerweile gibt es fur Chipkarten sogar einen B ASIC-Interpreter [Zeitcontrol]. Inter- 
preter, die dem Programm einer Anwendung einen eigenen geschiitzten Speicher zur 
Verfiigung stellen, sind im ubrigen nicht fur Fehlerbeseitigungen im Betriebssystem 
von Chipkarten geeignet, da sie auf diese Programm- und Datenteile konsequenterwei- 
se keinen Zugriff haben. 

| nachladbarer Programmcode J 



j Compillerter Programmcode j j int erpretierler Programmcode "j 

. — : 



j Programmcode in Maschinen- 
sprache der Zielhardware 



interpretierter Pseudo- 

f Assembler-Code 

— Teife einer Virtual Machine 
- vollstandige Virtual Machine 



Bild 5.27 Klassifizierungsbaum der Varianten, urn ausfuhrbaren Programmcode in Chipkar- 

ten-Betricbssy steme nachzuladen und dort auszufiihren. 

Das Urproblem aller Interpreter ist jedoch die langsame Abarbeitungsgeschwindig- 
keit, welche fur dieses Prinzip immanent ist. Um dieses Minus auszugleichen und urn 
den Programmcode fur den eigentlichen Interpreter so klein wie moglich zu halten, 
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gibt es mehrere Losungsansatze. Die einfachste Methode ist es, einen Pseudocode zu 
mterpretieren, welcher idealerweise den Maschinenbefehlen der Zielhardware moe- 
-hchst ahnlich sem sollte. Die AbarbHtungsgeschwindigkeft ist "durch die maschinen-" 
nahe Pseudosprache verhaltnismaBig hoch, und es kann maschinenunabhangiger Pro- 
granmicode benutzt werden. Speicherzugriffe walirend der Interpretation konnen 
uberwacht werden, was aber nicht zwangslaufig der Fall sein mufi. Eine lanosamere 
und programmienechnisch etwas aufwendigere Losung ist die Aufspaltung de°s Inter- 
preters m einen offcard-Teil (offcard virtual machine) und einen oncard-Teil (oncard 
virtual machine). Dieser Ldsungsweg wird bei vielen heutigen Java Card Implementa- 

SS^^Si dCn gro6en Vorteil dnes verlaBlichen Speicherschutzes und 

ouscanaiger Marrtwareunabhangrgkeit-Naebteilig-ist die Aufieilung des Interpreters iri~ 
off- und oncard-Teil. Dies bedmgt zwangslaufig einen kryptografischen Schutz beim 
Ubertragen von Programmen zwischen offcard-Teil und oncard-Teil des Interpreters 
da nut man,puliertem Progranimcode der oncard-Teil des Interpreters bewuBt zu einem 
Fehlverhalten gebracht werden kann. 

Die technisch optimale Losung ist ein vollstandiger Interpreter auf der Chiokane 
Damit ist es mSglich, in die Chipkarte beliebigen Programmcode zu laden und dort oh- 
ne Risiko fur andere auf der Chipkarte befindliche Anwendungen auszufiihren Aller- 
nn D , g hV St t l I0 ^ av ^ a f^ dazu «k* entsprechend groB, weshalb es sicherlich 
noch emige Jahre und mehrere Chipgenerationen dauem wird, bis diese Variante brei- 
ten Einzug in die Chipkartenwelt halt. 

5.10.1 Executable Native-Code 

Mikrocontroller fur Chipkarten haben zur Zeit meistens Prozessoren, die uber keinerlei 
Speicherschutzmechanismen oder Uberwachungsmoglichkeiten verfugen. Sobald sich 
der Programrnzahler mnerhalb eines fremden Maschinencodes fur den Prozessor be- 

ro? 1 S 6 S -t S T e ^° ntr °! le allef SpCiCher Und F ™™°™ bei diesem ausfuhr- 
baren Code. Es gibt dann keinerlei Moglichkeiten mehr, dieses ausfuhrbare Programm 
n semen Funktionen zu beschranken. Jede adressierbare Speicheradresse kann unter 
SraS? Speichermanager oder Handler gelesen und - sofem im RAM oder 
r*.f sc ^ eben J erden - Alle Speicherinhalte konnen dann natiirlich 
auch uber die Schmttstelle zum Terminal gesendet werden 

Genau dies ist die Schwachstelle bei ausfiihrbaren und nachladbaren Programmen 
Wurde man jedermann em Nachladen von Programmen erlauben, oder ware es durch 
Umgehung der Schutzmechanismen moglich, dann ist keine Sicherheit mehr fur ge- 
heime Schlussel oder Informationen innerhalb des gesamten Speicherbereichs ge^eben 
Dies ware der ideale Angriff auf eine Chipkarte. Diese Karte wurde sich nach auBen 
hm wie erne nicht mampulierte Karte verhalten. und mit einem speziellen Kommando 
konnten der gesamte Speicher ausgelesen oder Teile davon geschrfeben werden 

Ware das Laden nur einigen wenigen Anwendungsanbietern erlaubt - was mit einer 
gegenseitigen Authentisierung vor dem eigentlichen Laden des Programmers ohne 
weiteres durchfuhrbar ist - so ist das Problem auch nicht aus der W^chaSt Der 
Anwendungsanbieter kann ohne Einschrankungen uber die Grenzen seines ihm zu- 
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geteilten DFs auf geheime Infonriationen von anderen vorhandenen Anwendungen zu- 
greifen. Das System ware wiederum gebrochen. 

Doch gibt es noch ein weiteres stichhaltiges Argument gegen von Dritten nachladba- 
ren Programmcode. Um wichtige Funktionen im Betriebssystem nutzen zu konnen, 
muB der Ersteller der nachladbaren Datei alle Einsprungadressen und Aufrufparameter 
kennen. Die Betriebssystemhersteller erachten es aber fur die Sicherheit als relevant, 
daB sowenig wie moglich uber interne Ablaufe oder Adressen von Programmcode be- 
kannt ist. Zusatzlich miiBte auch noch sichergestellt werden, daB der eingebrachte 
Code genau das fehlerfrei ausfuhrt, was beabsichtigt ist, und nicht etwa ein trojani- 
sches Pferd enthalt. Dies kann dann wiederum nur eine unabhangige Instanz priifen. 

Die eleganteste und auch die wohl zukunftstrachtigste Losung ist der Einsatz einer 
hardware-unterstutzten Speicherverwaltung {memory management unit - MMU) zu- 
satzlich zum eigentlichen Prozessor in der Chipkarte. Diese priift den ablaufenden Pro- 
grammcode rnit einer Hardwareschaltung auf die Einhaltung seiner ihm zugewiesenen 
GienzglL Erst dann ware es ohne den Verlust an Sicherheit moglich, jeden Anwen- 



dungsbetreiber Programmcode ohne vorherige Priifung durch den Kartenherausgeber 
in die Chipkarte laden zu lassen. Diesem Anwender wiirde man den physikalisch zu- 
sammenhangenden Speicherbereich eines DFs zuweisen. Die MMU priift die zugeord- 
neten Speichergrenzen wahrend des Aufrufs eines im DF nachgeladenen Programms. 
Werden die Grenzen uberschritten, so kann man uber einen Interrupt den Pro- 
grammablauf unmittelbar stoppen und die Anwendung bis auf weiteres sperren. 1 



DF^ 



J execute- 



\ Code 



j/DF\__ 

.L _ 



EF 



T 


execuieable 




Code 



EF 



Bild 5.28 Die beiden unterschiedlichen Varianten zur Einbringung von ausfuhrbarem Pro- 

grammcode in ein ubliches Chiplcarten-Betriebssystem. Links als ausfiihrbare Datei 
und rectus als ASC {application specific commands). 

Fiir das Nachladen von nativem Programmcode in Chipkarten existieren zwei Vari- 
anten der Realisierung. In der ersten befindet sich der Programmcode in einem EF mit 
der Struktur , executable* 4 . Nach einer vorherigen Selektion ist das EF mit einem 
Kommando EXECUTE ausfiihrbar. Je nach Anwendung ist dazu vorher noch eine 
Authentisierung notwendig. Die Parameter fur den Programrnaufruf sind im Komman- 
do EXECUTE an die Chipkarte enthalten. Die vom Programm im EF erzeugte Antwort 
kommt als Teil der Antwort auf das Kommando zum Terminal zuruck. 



1 siehe auch Abschnitt 3.4.3 Zusatzhardware 
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Die zweite Variance gestaltet sich vom Prinzip her etwas anders. Man benutzt dabei 
einen objektorientierten Ansatz. Dieser ist unter andefem auch in der EN 726-3 als 
ApplicatiotrSpecific Commands (ASC) beschfiefren."Nach "dieser Nbfm~entlfalt"ein DF~ 
die vollstandige Anwendung mit alien ihren Dateien und anwendungsspezifischen 
Komrnandos. In einem in diesem DF intern vom Betriebssystem verwalteten Speicher- 
bereich kann Programmcode nachgeladen werden. Dies geschieht mit einem speziellen 
Kommando, das alle dafiir notwendigen Informationen an die Chipkarte sendet. Ist nun 
das betreffende DF selektiert und wird ein Kommando an die Karte gesendet, so priift 
das Betriebssystem, ob es zu den Nachgeladenen gehort, und ruft gegebenenfalls ohne 
weiteres Zutun den im DF befindlichen Programmcode auf. Ist hingegen ein anderes 
DF selektiert, so , ex istie rt das nachgeladene-Kommando in diesem- Kontext nic 



Betriebssystem 

i 

. i 



Kommando- APDU -»- | Ernpfangspuffer j ► 
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] Progranmv 
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Bild 5.29 Die Grundlage des Aufrufverfahrens fur in einem EF gespeicherten ausfuhrbaren 
Programmcode bzw. Programmen im Rahmen von ASCs (application specific com- 
mands) in einem ublichen Multiapplication-Betriebssystem fiir Chipkanen. 

Beispiel fiir in ein EF nachladbaren nativen Programmcode 

Es existieren mehrere groBe Chipkarten-Anwendungen, deren spezifische Betriebssy- 
steme ein Laden von ausfiihrbarem Programmcode nach der Personalisierung vorse- 
hen. Die Spezifikationen dazu sind aber in beinahe alien Fallen vertraulich, bzw. zum 
Teil ist bereits die Tatsache vertraulich, daB Programmcode nachgeladen werden kann. 
Deshalb sind in diesem Abschnitt die allgemeingultigen Grundlagen unabhangig von 
einem Betriebssystem aufgefiihrt und dann nachfolgend eine mogliche Realisierung im 
Detail dargestellt. 

Der nachzuladende Programmcode muB einige Grundvoraussetzungen erfiillen, da- 
mit er iiberhaupt auf der Chipkarte ausgefiihrt werden kann. So trivial es klingen mag, 
aber die wichtigste Voraussetzung ist, daB der Prozessortyp (z.B.: 8051, 6805) bekannt 
ist. Gerade in einer heterogenen Umgebung mit vielen unterschiedlichen Chipkarten- 
Mikrocontrollern ist die Einhaltung dieser Forderung oft durchaus mit einigem Auf- 
wand verbunden. Einher geht, daB ebenfalls das Betriebssystem der Chipkarte ein- 
schlieBlich API (application programming interface) mit alien Einsprungadressen, 
Uber- und Riickgabeparametem bekannt sein muB. 
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Der nachzuladende Programmcode - es handelt sich dabei immer urn Maschm- 
encode der Zielprozessors (d.h. Native-Code) - muB entweder so programmiert sein, 
daB er relokatibel ist, oder die Chipkarte muB ihn wahrend des Ladens on-the-fly selber 
relokieren. Die Forderung nach Relokatierbarkeit (d.h. Verschiebbarkeit des Pro- 
grammcodes im Speicher) muB deshalb aufgesteUt werden, weil die Speicheradresse 
fur die Prograirunablage nur das Chipkarten-Betriebssystem kennt und der auBeren 
Welt unbekannt ist. In der Regel wird der Programmcode bereits be! der Software- 
entwicklun- so erstellt, daB er relokierbar ist. Dies bedeutet konkret, daB beispiels- 
weise in dilsem Programm keine Spriinge an absolute physikalische Adressen gemacht 
werden diirfen, sondem lediglich Spriinge relativ zur Adresse" des Sprungbefehls. 

ErfUllt der Programmcode alle diese Voraussetzungen, dann kann er pnnzipiell in 
den Speicher einer Chipkarte-geladen-and-dor^ausgefiih rt w e rden l>.r PxogaTOde 



kann naturlich je nach Bedarf aufgebaut sein. Eine moghche Struktur zeigt das folgen- 
de Bild wobei diese aber je nach Betriebssystem vollig verschieden sem kann. Das er- 
ste Datenelement in dem Beispiel ist ein eindeutiges Kennzeichen fur das Chipkarten- 
Betriebssystem, daB es sich urn Programmcode handelt. Allgemein bekannt ist so ein 
Kennzeichen auch als „Magic Number". Diese kurze Bytesequenz setzt sich beispiels- 
weise bei Java-Class-Dateien aus den vier Bytes 'CAFEB ABE" zusammen. 

Im AnschluB an das Kennzeichen folgt bereits der Programmcode, welcher in die- 
sem Beispiel noch mat in vier Telle aufgegliedert ist. Der erste Teil ist fur alle notwen- 
diaen Initialisierungen, Sicherung von Daten und ahnliches vorgesehen. Nach dieser 
Startup-Routine folgt die eigeniliche Fuhktionsroutine, welche den Programmcode fur 
die gewiinschte Aufgabe enthalt. Daran schlieBt sich das Pendant zur Startup-Routine 
an die Shutdown-Routine. Diese stellt sicher, daB das Programm korrekt abgeschlos- 
sen wird und fuhrt dazu nach Bedarf eine Riicksicherung von Daten oder ggf. Ande- 
rungen auf dem Stack durch. 

Optional und am SchluB dieser drei Programmteile befindet sich das viene Pro- 
grammelement. Es kann Programmcode enthalten, der resistent in die Software der 
Chipkarte eingebunden werden soil. Typischerweise wiirden hier Bugfixes fur das 
Chipkarten-Betriebssystem abgelegt. Die vorangehenden drei Routinen wiirden Zeiger 
Oder Handles so verandern, daB diese Programmroutinen permanent in die Pro- 
«rammablaufe des Betriebssystems eingebunden sind. Das Ganze verhalt sich sehr 
IhnUch wie die noch aus DOS-Zeiten bekannten TSR-Programme {terminate and stay 
resistant) welche sich nach einem einmaligen Aufruf bis zum nachsten Reset fest im 
Betriebssystem verankerten. Die resistenten Programme in diesem Fall waren jedoch 
nach einmaligem Aufraf auf Dauer fest installiert und nicht nur fur eine Sitzung. 

Es wird hier davon ausgegangen, daB das nachgeladene Programm nut emem 
CALL-Befehl aufgerufen wird und mit einem RETURN-Befehl zum Aufrufer zuriick- 
kehrt Pnnzipiell ware auch ein direkter Sprung mit JUMP auf den ersten Maschmen- 
befehl moglich, dies hatte aber den Nachteil, daB dann dem aufgerufenen Programm 
nicht bekannt ist, von wem es aufgerufen wurde. 

Zur Absicherung gegen unbeabsichtigte Veranderung sollte der gesamte Datenblock 
noch mit einem Fehlererkennungscode (error detection code - EDO abgesichert sem. 
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Altemativ dazu- wurde -sich hier naturlich auch eine digitale-Signaturals" zusatzlicher " ~ 
Schutz anbieten. Die Chipkarte wurde dann den offentlichen Schlussel besitzen und 
der Ersteller des Programmcodes den dazugehorigen geheimen Schlussel. Damit ware 
bindend sichergestellt, daB authentischer Programmcode auf der Chipkarte gestartet 
werden kann. 

ausfuhrbarer 
Programmoode 



j Kennzeichen 


Startup- 
Routine 


Funktions- 
Routine 


Shutdown- 
Routine 


resist ente 
Routine 


EDC ! 

J 




1 


r 





CALL RETURN 



Bild 530 Moglicher Aufbau eines nativen und in ein EF nachladbaren und ausfuhrbaren Pro- 
grammcodes. 

Der nachgeladene Programmcode kann entweder in einem EF gespeichert werden 
Oder in einem fur die auBere Welt unsichtbaren Speicherbereich fur Programme inner- 
halb eines DFs. Im folgenden wird die erste Variante genauer aufgezeigt, da diese in 
der Praxis wesentlich haufiger anzutreffen ist. 

Ideal zur Ablage von Programmcode sind EFs mit der Struktur ^transparent" geeig- 
net, da diese zweckmaSig mit dera UPDATE BINARY-Kommando und Offsetangabe 
in mehreren Teilstucken schreiben lassen. Zudem ist ihre maximale GroBe von uber 
65 ^y 1 * selbst fQr unrfangreiche Programme mehr als ausreichend. Diese EFs konnen 
die Eigenschaft ^executable" haben, so daB in ihnen gespeicherter Programmcode di- 
rekt mit dem Kommando EXECUTE aufgerufen wird. 

Manche Betriebssysteme besitzen aber auch eine von „transparent" abgeleitete Da- 
teistmktur, welche sich dann ^execute" nennt. Fur die auBere Welt ist dies nicht von 
besonderer Bedeutung, zumal in der Regel auf beide Varianten mit UPDATE BINARY 
und EXECUTE zugegriffen werden kann. Mit dem FID bzw. Short-FID kann das EF 
selektiert werden. Die Zugriffsbedingung zum Lesen ist grundsatzlich auf „never" ge- 
setzt. Das Schreiben von Daten ist in der Regel nur nach vorheriger Authentisierung 
und mit Secure Messaging erlaubt. 

Die beiden Ablaufe Bild 5.31 und Bild 5.32 zeigen im Uberblick, wie Programm- 
code auf sichere Weise in das EF einer Chipkarte geladen werden kann. Solfte kein 
entsprechendes EF vorhanden sein, dann muB dieses vorher erzeugt werden. Im zwei- 
ten Ablaufbild ist uberblickhaft dargestellt, daB das EF zuerst muB und anschlieBend 
der Programmcode mit dem Kommando EXECUTE gestartet werden muB. Das Kom- 
mando sieht optional eine Dateniibergabe im Kommando-Body vor. Analog verhalt es 
sich mit der Antwort, in welcher Daten bei Bedarf an das Terminal zuriickgegeben 
werden konnen. Das aufgerufene Prograrnm muB dazu naturlich die Daten aus dem 
Empfangspuffer lesen, auswerten und dann die Antwort in den Sendepuffer zuriick- 
schreiben. 
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Hintergrundsystem Chipkarte 

selektiere ein EF mit der Stmktur execute " 

gegenseitige Authentisierung von Hintergrundsy- 
stem und Chipkarte 

schalte Secure Messaging ein 

sende n • UPDATE BINARY-Kommando mil dem 
Datenteil als ausfiihrbaren Programmcode, ee- 

s e hiitz t m it Sc i uie -Messagm g : — — 



Bild 5.31 Ein moglicher Ablauf beim Laden von ausfuhrbarem Programmcode in ein bereits 

vorhandenes EF mit der Stmktur ..execute". Die Zugriffsbedingung fur UPDATE 
BINARY ist eine gegenseitige Authentisierung zwischen Chipkarte und Terminal 
sowie die Dateniibcrtragung mit Secure Messaging. 



Hintergrundsystem Chipkarte 

Selektiere EF mit ausfuhrbarem Programme ode — — __________ 

Sende EXECUTE-Kommando * - Prufe Kennzeichen (mafic number) des Pro- 

gramms 
- Prilfe EDC des Programms 
~ Rufc den crstcn Maschinenbefehl mit CALX, auf 

Bild 532 Ein moglicher Ablauf beim Starten von ausfuhrbarem Programmcode. Dieser ist in 

diesem Beispiel in einem EF mit der Struktur ^execute" abgelegL 

Aufgrund der hphen Anforderungen betreffend eine eindeutige Identifizierung von 
Mikrocontroller, Betriebssystem und intern Software-Schnittstellen sowie des System- 
Managements ist es ublich, den Download von Programrnen nur online zu einem Hin- 
tergrundsystem durchzufiihren. Die dort befindlichen Datenbariken enthalten entweder 
alle notwendigen Informationen in Abhangigkeit von einer eindeutigen Chipnummer 
oder erhalten diese Informationen online in einer Ende-zu-Ende-Verbindung direkt von 
der Chipkarte. In Abhangigkeit davon wird dann ein vorhandenes Programm mit der 
gewiinschten Funktionalitat ausgewahlt und mit den geforderten Sicherheits- 
mechanismen zur Chipkarte ubertragen. Die geheimen Schlussel dazu werden im Hin- 
tergrundsystem iiblicherweise ausschlieBlich innerhalb eines Sicherheitsmoduls ver- 
waltet und benutzt. Der ubliche Ablauf dazu ist im nachfolgenden Bild nochmals auf- 
gezeigt. 

Die oben beschriebene Art und Weise der Einbringung von nativem Programmcode 
in Chipkarten besitzt einige fur die Praxis attraktive Vorteile. Das Verfahren ist un- 
kompliziert, robust und mit geringem Aufwand an Programmcode in einem Chipkar- 
ten-Betriebssystem realisierbar. Der ausgefuhrte Programmcode mu8 nicht interpre- 
tiert, sondern kann direkt vom Prozessor abgearbeitet werden. Daraus resultien eine 
hohe Ausfiihrungsgeschwindigkeit sowie die Moglichkeit, auch komplexe Algorith- 
men (z.B.: DES, IDEA o.a.) mit diesem Verfahren nachzuladen. 
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HIntergrundsystem Schnlttstefle Chipkarte 
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-OS-Version 
1 -OS-API 



. Prograrnrncodes 

: . + gegenseitige 

' Authentisierung 

Info: "Procjrarnrn- ■ 
codegeladen" ; „ EFExaero u gen 



I 



Programmcode in 

EFExe laden " * ■ 



Bild 533 Ablauf beim online-Nachladen von nativen Prograrnrncodes in EFs einer Chipkarte 

von einem Hintergrundsystem aus. Es kann bei diesem Schema abhangig vom Chip- 
karten-BetriebssysTem und der Mikrocontroller-Hardware unterschfedlicher Pro- 
grammcode zur Chipkarte ubertragen werden. Der dargestellte Ablauf konnte bei- 
spjeisweise sehr gut in einer GSM-Anwendung realisiert werden. 

Interpreter-basierte Systeme konnen dies durch die geringe Abarbeitungsgeschwin- 
digkeit des Prograrnrncodes auch auf absehbare Zeit nicht ieisten. So lange keine hard- 
warebasierte Speicherverwaltung (MMU) die wahlfreien Speicherzugriffe einschrankt 
kann dieses Verfahren hervorragend fur die Behebung von Fehlem in der Chipkarten* 
Software nach Kartenausgabe genutzt werden. Dies ist fur den Fall des Falles eine 
Hintertur, die einzig und allein durch diese Art der Softwarenachladung erreichbar ist 
da beispielsweise Technologien wie Java auf Chipkarten eine strikte und unbedin-te 
Speichersepanerung verwirklichen. Ist eine MMU vorhanden, dann konnte ggf. imrrler ' 
noch iiber einen Administrator-Modus die Speicheriiberwachung vorubergehend deak- 
tiviert werden. 

Dies fuhrt nun auch schon zu den Nachteilen. Das Nachladen von ausfiihrbaren nati- 
ven Programmen bedingt groBes Wissen urn die eingesetzte Hardware bzw das Be- 
tnebssystem der Chipkarte. Unter Umstanden muB fur jede dieser Varianten ein eigen- 
es Programm gleicher Funktionalitat vorgehalten werden. Die zweite groBe Schatten- 
seite dieser Methode ist, daB sicherheitstechnisch die Notwendigkeit besteht, daB nur 
der Kartenherausgeber den Programmcode erstellen oder erstellen lassen kann. Es muB 
stnkt verboten sein, fremde und unbekannte Programme in die Chipkarte zu laden, da 
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diese ab dem Start das Kommando uber den Mikrocontroller ohne weitere Reglemen- 
tierun^smoslichkeiten erhalten. Sie konnten dann beispielsweise die geheiraen Schlus- 
sel der anderen auf der Karte befmdlichen Anwendungen auslesen und liber die I/O- 
Schnittstelle zum Terminal senden. . 

Einen schwachen Schutz vor Angriffen uber diesen Mechamsmus stellen Evaluie- 
run^en des Programmcodes durch den Kartenherausgeber dar. Besser jedoch ist in die- 
sem Fall eine hardwarebasierte Speicherverwaltung, die dem nachgeladenen Programm 
nur einen bestimmten Bereich im RAM und EEPROM zur Verfugung stellt und bei 
dem Versuch der Uberschreitung das gestartete Programm sofortbeendet.i Damit kon- 
nen die einzelnen auf der Chipkarte befmdlichen Anwendungen vollstandig voneinan- 
der abgeschottet werden. Zur Zeit behilft man sich jedoch noch mangels entsprechen- 
der MMUs mit der Prufung der nachzuladenden Programme. 

5.10.2 Java Card 

Im Jahr 1996 wurde von Europay eih Papier uber OTA {open termmar-archirecttirey- 
vor-estellt. in welchem ein Forth Interpreter fur Terminals beschrieben und m weiten 
Teifen spezifiziert war. Der Zweck war, eine einheitliche Softwarearchitektur fur Ter- 
minals zu schaffen, urn die Grundlage fur eine hardwareunabhangige Termmal- 
programmierung zu schaffen. Dann mufite man eine bestimmte Anwendung (z.B. Be- 
zahfen mit Kreditkarte) nur noch ein einziges Mai programmieren, und diese Software 
wurde auf alien Terminals der verschiedenen Hersteller unverandert laufen. Dieses 
Modell wurde aber bisher nie vollstandig realisiert, es sorgte allerdings in der Chip- 
kartenwelt fur ausfuhrliche Diskussionen. 

Als dann im Herbst 1996 bekannt wurde, daB die Firma Schlumberger eine Chip- 
karte entwickelt, welche Programme abarbeiten kann, die in der Programmiersprache 
Java erstellt sind, hielt sich das Erstaunen in Grenzen. Das Prinzip ernes Interpreters 
auf speicherplatzarmen Mikrocontrollem war durch die Open Terminal Architecture 
(OTA) schon reichlich bekannt. Die veroffentlichte Spezifikation Java Card 1.0 sah zur 
Einbindun* von Java in das ISO/IEC 7816-4 Betriebssystem ein dazugehonges API 
{application programming interface) vor, so daB von Java aus auf das bei Chipkarten 
iibliche Dateisystem mit MF, DFs und EFs zugegTiffen werden konnte. 

Nach kurzzeitiger Verwunderung vieler Hersteller von Chipkarten-Betnebssystem- 
en warum eine Sprache wie Java, die einen iiblichen Speicherbedarf weit jenseits von 
einem Megabyte hat, auf Chipkarten verwendet werden soli, kam es aber bereits im 
Friihjahr 1997 zu einem ersten Treffen von nahezu alien groBen Chipkartenherstellem 
und der Firma Sun, die Java entwickelt und bekanntgemacht hat. 

Dies war die erste Konferenz des inzwischen sogenannten Java Card Forums (JCF). 
welches das international tatige Standardisierungsgremium fur Java auf Chipkarten ist. 
Die Aufgabe der technischen Gruppe des Java Card Forums ist es, eine Untermenge 
von Java fur Chipkarten festzulegen. den Rahmen fur den Java Interpreter (d.h. die Ja- 
va Virtual Machine - JVM) zu spezifizieren und sowohl ein atlgemeines, als auch an- 



1 siehe auch Abschnitt 3.4.3 Zusatzhardware 
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Information Disclosure Statement with Regard to the Non- 
English Language Document 

5 In Ranke, Wolfgang et . al, „Handbuch der Chipkarten. Aufbau 
- Funktionsweise - Einsatz von Smart Cards", Carl Hanser 
Verlag, Munich 1999), pages 191 - 193, various authentica- 
tion methods between chip card and terminal are described, 
and on pages 252 - 261, the above document relates to chip- 

10 card operating systems with a reloadable program code. 
Various advantages are set forth which result from the re- 
loadability of program codes in chip cards, e.g. the possi- 
bility of removing program errors in fully personalized 
cards (page 252, last line, up to page 253, first line), 

15 and the possibility of an application provider introducing 
an encryption algorithm only known to themselves into the 
chip card (page 252, second but last paragraph) . Two ways 
of reloading are indicated, specifically reloading in the 
form of native code or in the form of an executable program 

20 code to be interpreted (picture 5.27). The problems associ- 
ated with reloading native codes, i.e. the lacking possi- 
bility of monitoring a downloaded executable code (page 
254, third but last paragraph), are said to be solvable by 
mutual authentication prior to the actual loading of the 

25 program code (page 254, third but last line) and by provid- 
ing an MMU (page 255, third paragraph) . Complex algorithms 
such as DES, IDEA are given as examples of reloadable na- 
tive codes (page 259, last two lines) . 
**. t- - . - 

30 Unlike the subject-matter of the newly submitted . independ- 
ent claims, the above document does not disclose a volatile 
memory for storing part of an algorithm code which is re- 
ceived via a data interface. In addition, like US 
4,777,355, the above document does not address the issue of 

35 the chip card's energy supply. 
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